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I . THE LAF AS AN INFORMATION SYSTEM [1,2,3] 



A. MISSION, GOAL, AND OBJECTIVES OF THE LAF 

1 . Definition of the LAF 

The LAF is an army unit that comprises a balanced 
force of essential ground arms and services so organized and 
equipped as to make it tactically and administratively self- 
contained. That is, it can conduct by its own means ground 
operations of general importance. It can strike or pene- 
trate effectively, maneuver readily over any type of terrain 
and absorb reinforcing units easily. 

2 . Mission of the LAF 

The mission of the LAF can be any or all of the 
following ; 

a. To seize and secure an area and to deny its use to 
the enemy. 

b. To dominate key or vital land areas and their popu- 
lation and resources. 

c. To destroy or capture enemy military forces. 

3. Goal of the LAF 

The goal of the LAF is the successful fulfillment 
of its specified mission. 



10 



4 . Objectives^ of the LAF 

The objectives of the LAF are concrete and specific 
accomplishments necessary to the achievement of its goal. 

The main objectives of the LAF are: 

a. With respect to Personnel 

- Good Health 

- High degree of Training and Education 

Discipline and High Morale 

2 

b. With respect to Equipment 

- High Performance 

- Good Maintenance 

c. With respect to Functionality 

- Precision 
Actions in Time 
Effectiveness 
Low Cost 

5 . Dependency and Relations Among Mission^ Objectives 
and Goal 

The mission of the LAF is expressed by the military 
manuals in a general manner and needs to be specified ex- 
plicitly either by the orders of the LAF's superior echelon 
or by the LAF's command. This specification is an aftermath 
of considerations of several factors like the strength and 
the operational ability of the LAF, the strength and behavior 



^These must not be confused with the terrain objectives 
on the battlefield. 

2 

Weapons, Munition, Ammunition, Vehicles, Facilities, Supplies. 
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of the enemy, the land morphology, the weather conditions. 

As these factors are related to time, they confound the 
tactical situation. The mission's specification is an adapta- 
tion over time. The estimation of the situation is a con- 
tinuing process and changed conditions may call for a new 
decision at any time that could modify the mission's 
specification . 

The objectives of the LAF are dependent on the mission's 
adaptation in a considerable way. For example, military 
operations conducted under conditions of extreme cold and 
deep snow require special equipment and training for the 
LAF designated to conduct such operations. The objectives 
are also strongly related to each other. For example, a 
high degree of personnel training results in good maintenance 
and performance of the equipment. The high performance of 
the equipment facilitates the personnel training. A high 
degree of personnel training and high performance of the 
equipment leads to an effective functioning of the system. 

The achievement of the LAF's goal is exclusively 
dependent on the accomplishment of its objectives. Moreover, 
the achievement or failure of the goal can cause an adapta- 
tion of the mission. For example, after a successful attack 
when the enemy is no longer able to maintain his position, 
then the mission of the LAF must enter a new phase; a pursuit 
must be launched. 

Figure 1.1 shows the dependency and the relations 
among mission, objectives and goal of the LAF. 
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6 . The LAF Is a Closed Loop System 

A system is a combination of diverse but interacting 
elements integrated to achieve its overall purpose. The 
elements may be devices and/or human beings concerned with 
processing materials, information and energy. A feedback 
loop for returning part of the output to the input in order 
to improve performance is an important functional component 
in many systems. The concept of feedback is not new; it is 
inherent in many biological systems, and it is found in well- 
established social systems. However the formulation of the 
principles of feedback is a recent achievement, credited to 
H.S. Black in his studies in 1934, and exploitation of this 
new understanding has come in just the last few years. 

The LAF is a feedback or a closed loop system. That 
is, it provides command and staff with a comparison of both 
actual and desired output. The input of the LAF is its speci 
fied mission, the desired output is either the accomplishment 
of its objectives in the time of peace or the achievement of 
its goal in the time of war. This comparison can trigger 
the LAF's command and staff to take action in order to bring 
desired and actual output into correspondence. So the compar 
son of desired and actual output requires an explicitly docu- 
mented specification of the mission and a measurement of the 
actual output. The measurement of the actual output comes 
from either evaluations with respect to the LAF's objectives 
or the estimation of the situation with respect to the LAF's 
goal . 
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Each closed loop or feedback system is effective if 
it can respond fast for the necessary control action. Other- 
wise the time lapse maybe so great that belated control action 
can make the situation worse [Ref. 1, p. 61]. Such systems 
are said to be unstable. In an unstable system, a random 
disturbing input may give rise to decoordination of the 
system. The LAF is an unstable system, thus a sudden unfore- 
seen enemy action, the lack of fast control response or 
misestimation of the situation can often be a catastrophe 
for the LAF. By nature, an unstable system is difficult to 
control. On the other hand, the requirements for certain 
results of a military action impose difficult planning prob- 
lems for the staff, who are the control engineers of the LAF. 
The use of automated tools will be, if not a panacea, at 
least a means to maximize the control abilities of the staff 
and to minimize the unforeseen situations . 

Figure 1.2 presents the LAF as a closed loop system. 

B. THE LAF: A SYSTEM OF SYSTEMS 

The LAF is a system which is composed of two smaller 
entities which are also systems. These systems are the 
LAF ' s staff, a planning and control functional system and the 
totality of the LAF subordinate echelons which constitute 
an executive system. These systems are also divided into 
subsystems. This work focuses on the staff since the sub- 
systems of the executive system (small groups and units) are 
beyond its scope. 
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The Staff and Its Subsystems 



The mission of the staff is: 

1. To conduct methodical analysis of any tactical or 
procedural problem in the activities of the LAF, to 
elaborate fast, precise and satisfactory solutions 
and to present these solutions to the LAF ' s Commander 
General Officer in order to reach a decision. 

2. To interpret with accuracy the decisions of the General 
into orders and to issue these orders at the proper 
time . 

3. To always be informed in time on the situation and 
to be sure that all the relevant factors have been 
considered. 

4. To be able to quickly control and coordinate the 
operations . 

5. To minimize the probability of errors. 

6. To relieve, as much as possible, the Commander General 
from the supervision of activities that are not vitally 
important . 

The basic subsystems of the staff are those of personnel, 
intelligence, operations and logistics. These subsystems 
have a number of significant functions that should be 
considered. 

1 . Personnel 

Personnel functions are intended to keep the LAF in- 
formed on personnel strength, the administrative situation. 
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the current battle personnel needs and changes in priority. 
These functions include: 

a. Developing Estimates 

b. Maintaining LAF ’ s Strength Status 

c. Supervision of Personnel Management. 

2 . Intelligence 

Intelligence functions are intended to provide the 
LAF with intelligence information on which to base current 
tactical decisions. The functions performed include: 

a. Planning of Information Collection 

b. Information Collection Management 

c. Information Analysis and Verification 

d. Dissemination of Analysis Products 

e. Coordination of Counterintelligence 

f. Coordination of Informants 

g. Planning and Coordination of Reconnaissance. 

3 . Operations and Training 

Operations and training functions are intended to 
support the LAF by having highly trained personnel and by 
controlling immediate combat operations and sustaining battle. 
The functions performed include: 

a. Preparation of Training and Education Plans 

b. Coordination of Training 

c. Coordination and Processing Evaluations 

d. Preparation of Operation Plans 

e. Coordination of Tactical Troop Movements 
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f. Coordination of Nuclear and Chemical Weapons 

g. Maintaining an Operation's Estimate 

h. Planning and Processing Air Support Requests 

i. Supervision of Electronic Warfare. 

4 . Logistics 

Logistics functions are intended to coordinate the 
logistics requirements of the LAF with the tactical aspects 
of the LAF ' s activities. The functions performed include: 

a. Planning Supply, Services, and Maintenance 

b. Monitoring the Logistic Situation and Capability 

c. Monitoring the Medical Activity 

d. Monitoring the Airlifting of the LAF. 

A well-working staff speeds up the elaboration of 
the information and transforms it to useful material for 
decision making. The introduction of automated information 
processing means will make the staff more productive by mini- 
mizing the delays in the preparation and distribution of the 
estimations, plans, and directions. 

C . THE LAF ’ S INFORMATION NEEDS 

The information that a LAF must elaborate to meet its 
operational needs is generated by its internal reporting 
structure and by its external environment as well. 

The information generated is not simply useful to any 
army unit but is of vital importance. The whole mission's 
adaptation is based on the information generated in the LAF ' s 
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internal and external environment. Good exploitation of 
information leads to better estimations of the situation 
which leads to better decision making. Lack of information 
or misinterpretation of the information may be fatal, not 
only for the success of a tactical action on the battlefield 
but also for the existence of the unit itself. We could say 
that no tactical action is possible without information--it 
is the oxygen for every army organism on the battlefield. 
Because of this "starvation" for information, there is the 
intelligence subsystem of the staff which has as its primary 
role the coverage of the needs of the LAF for exploitable 
information. 

Fig. 1.4 shows the LAF ' s main information generators. 

At each management level, the specific requirements for 
information vary. The different information uses and re- 
quirements at each command & management level are sumonarized 
in Fig. 1.5. 
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II. MODELING A STAFF ASSISTANT COMPUTER SYSTEM (SACS) [4,5] 



A. AUTOMATION NEEDS — EXPECTATIONS 

Before making the configuration of any computer system for 
assisting the staff functions, the needs of this system should 
be identified. 

Although there are problems inherent in specifying the 
requirements to be met by something that does not yet exist 
(similar to convincing a farmer of his need for a tractor 
he has never seen) , a SACS is expected to meet the following 
requirements : 

1. Exchange data with other tactical data systems 

2. Build and maintain data bases 

3. Perform tactical analysis functions to support control 
actions and decision making 

4. Provide displays and graphics to support tactical 
operations and daily procedures 

5. Interface with detection systems 

6. Provide functions to support tactical war games for 
the LAF ' s senior personnel training. 

Figure 2.1 presents a matrix which lists the automation 
needs--expectations for the SACS, with respect to staff 
functional subsystems. 
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B . PROBLEMS 



The expansion of automated assistance for staff activi- 
ties is inevitably accompanied by two major problems; 

1. The machine problem--that of making computing power 
available to staff personnel 

2. The human problem — that of motivating staff personnel 
to utilize computers. 

Attempting a solution to the first problem, a SACS model 
will be presented which, if completed and finally implemented, 
could insure the availability of computer resources throughout 
the staff environment. The solution to the problem of user 
motivation for exploitation of automated assistance will be 
embodied in a proposed user communications pattern. 

C. SACS DEFINITION 

SACS must be a secure, militarized, automatic system 
composed of the automatic data processing elements: 

1 . Hardware 

2. Firmware 

3. Software 

4. Communications Network, 

required for performing the receiving, filtering, processing, 
storing and correlating of input data and also for printing 
and disseminating the information product. This is to sup- 
port the staff in increasing its productivity and the quality 
of its work and to support commanders in their decision making. 
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D. SACS HARDWARE COMPONENTS DESCRIPTION 



SACS must have the following hardware components in order 
to accomplish its intended task. 

1 . LAF Main Computer (LMC) 

The LMC must provide the major computing capability 
in the LAF. It must be able; 

a. To maintain large data bases 

b. To perform numerical calculations 

c. To perform filtering 

d. To perform correlation of information 

e. To respond to queries 

f. To support other required processes and algorithms 

g. To accept and transmit messages from and to SACS users 
and interoperating systems 

h. To perform color graphic compositions. 

The LMC can be a supermini system in order to cover 
the above listed requirements, in a satisfactory way in terms 
of accuracy and fast response. 

2 . The Peripheral Control Unit 

The PCU must be a small scale computer capable of 

3 

storing messages and color graphics data, prompting for mes- 
sage and color graphic composition and enabling the several 
consoles to interact with the LMC and to accept messages and 
pictures from the detection systems. 



3 

The color is considered necessary to enable a vivid 
illustration of maps, friendly and foe force dispositions, etc. 
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3 . The Tactical Analysis Console (TAG) 

The TAG must provide the user with the capability to 
have color graphics and alphanumeric input and output with 
or without an illuminated color map background and color hard- 
copy output. TAGS must be connected to PGUs and must have a 
color display, a keyboard, a "mouse," a printer, and a plotter. 
The TAG must be capable of input and output of formatted or 
free text and of providing the user with the capability to 
review, store, manipulate and disseminate data on request and 
automatically . 

4 . The Large Display Panel (LGP) 

The LDP must be a computer driven large screen which 
will permit the integration of tactical command and control 
data on a universal traverse mercator map background and must 
facilitate user interaction with the data base. It must pro- 
vide the user the capability to create new color displays 
interactively, display information from the data base through 
direct communication with the LMG or indirectly through a 
connection with a PGU, update the data base, and store and 
retrieve displays. The LDP must have sufficient memory for 
storing the display symbology used in conjunction with standard 
military maps. 

5 . The Geometry Engine (GE) Style Subsystem (GESS) 

4 

The GESS must provide realistic visual simulation for 
real-time manipulation of geometry and other information taken 



4 

See "The Geometry Engine, a VLSI Geometry System for 
Graphics," by J.H. Glark, Gomputer Graphics, July 1982. 
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by detection systems. The GESS must output smooth continuous 
curves of 2D and 3D transformations and sharp readable textual 
descriptions of the behavior of the corresponding displayed 
object pictures. 

6 . The Detection Mapping Modulator (DMM) 

The DMM must interpret the signals which are received 
by the detection systems and which are interpreted locally 
into radar screen videos, into target geometric elements, 
and routed to the SPCU. 

7 . The Special Purpose Control Unit (SPCU) 

The SPCU must have the capability to control the 
outputs of the DMM, to compose the target information collected 
by adjacent detection systems with overlapped observation 
areas into integrated target information of larger areas 
(e.g., the combat zone of the LAF) , and to feed appropriately 
the GESS with the geometric elements of the corresponding 
targets . 

8 . The Comm.on Tactical Console (CTC) 

The CTC must be used for the display of, and interaction 
with computer stored data. It must be a small, transportable 
device capable of sending and receiving alphanumer ics and 
unsophisticated graphics through the PCU. The CTC must be 
equipped with one color plasma display, a keyboard and a 
printer. For alphamomeric data, the CTC must provide the 
user the capability to display prompt message composition, 
edit messages, and input and output messages in formatted 
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or free text. For simple graphics data, the CTC must provide 
the user with the capability to create new displays inter- 
actively, display information from the database indirectly 
through connection with a PCU, update the database and store 
and retrieve displays of military symbology. 

E. SACS HARDWARE TOPOLOGY AND WORKSTATIONS 

SACS hardware components must be located at the LAF 
tactical command post and at some of its subordinate echelon 
commands . 

1. LAF Tactical Operation Center 

a . the LMC 

b. the GESS, SPCU and DMM 

c. One PCU, one LDP, one TAC and one CTC 

2. The Personnel Subsystem 

a . One PCU 

b . One CTC 

3. The Intelligence Subsystem 

a . One PCU 

b. One TAC 

c . One CTC 

4. The Operations Subsystem 

a. One PCU 

b . One LDP 

c . One TAC 

d. One CTC 
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5. The Logistics Subsystem 

a . One PCU 

b . One TAG 

c . One CTC 

Figures 2.4 and 2.5 show the workstation organizations 
of the several subsystems. Some CTCs should also be given to 
the subordinate commands of the LAF if the LAF happens to be 
an independent brigade. If the LAF is a larger unit then it 
will have subordinate LAFs having their own SACSs. 

F. SACS SOFTWARE COMPONENTS DESCRIPTION 

1 . Enemy Situation Applications Software 
a. Enemy Situation Data (ESD) 

The ESD file must contain data and intelligence 
concerning enemy units, equipment, personnel, installations 
and activities. The application program associated with this 
file should provide for collection, storage, dissemination 
and selective retrieval of current enemy information. The 
major components of ESD file entries must be: intelligence 

subject; combat activity; unit element, equipment and location; 
morale; losses; weapon system activities; target identification 
and target characteristics. Related to each ESD message should 
be a list of users interested and authorized for the use of 
data contained in the messaae. Users authorized interest 
may be indicated in the following ways: (1) Users are speci- 

fied as interested with the submission of the message; (2) An 
incoming ESD message satisfies the user criteria for a standing 
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request for information; (3) A reviewer of the incoming mes- 
sage determines those interested in the message. Authorized 
users of enemy information may indicate their interest in 
messages as a means of retrieving data from the file. All 
system users, collection agents and sources may and should 
provide data for this application. The ECD in few words 
should provide the basic intelligence reporting mechanism for 
system users and should form the basis for developing enemy 
order of battle, targeting and other processed intelligence. 

b. Enemy Order of Battle (EOB) 

The EOB file should contain processed and evalu- 
ated information about enemy units and their structure. The 
corresponding application program should provide the user with 
the capability to enter, maintain and process enemy force 
information and to identify those elements of the enemy not 
yet located or whose location data is suspect. The major EOB 
file entries should be; unit identification, location, 
subordination, status, combat activity, and combat effectiveness. 

c. Filter 

Filtering must be a process which should provide 
the capability for checking incoming ESD data for redundancy 
with the current data base. 

d. Correlation 

Correlation must be a process which should provide 
the capability for relating new ESD data to those existing in 
the database. 
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2 . Friendly Situation Application Software 



a. Unit Operations Report (UOR) 

The UOR will be a process which must permit auto- 
matic record communication between the LAF and its subordinate 
echelons with respect to enemy activity, weather, terrain 
and tactical activity. Provision is to be made for entry, 
dissemination, storage and selected retrieval of UOR messages. 

b. Task Organization (TO) 

The TO file should contain information on the 
assignment and attachment of friendly forces. The corres- 
ponding application program should provide the Operations Sub- 
system personnel the capability to enter, retrieve, and modify 
proposed changes to the task organization. This application 
will also store task organization changes planned for future 
use and change the TO file on order. The major TO entries 
should be: Unit designation, type, subordination. 

c. Tactical Dispositions (TD) 

The TD file should contain geographic data related 
to combat support elements, service support locations, and 
certain tactical control measures. The major entries should 
be unit identification, location, type of location like com- 
mand post, center of mass, objectives, blocking and delay 
ground points, boundaries, coordination lines, assembly areas, 
etc . 
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3 . Applications Support Software 



a. Battlefield Information Reports (BIR) 

The BIR should contain the major subordinate com- 
bat maneuver elements and other designated units. The con- 
tents should include location, activity, intensity of conflict 
and the commander's perception of the situation. This report 
should be transmitted at specified intervals to LAF tactical 
command post. 

b. Management of Intelligence Collection (MIC) 

The MIC should be a function which will provide 

intelligence personnel with a set of files and processes to 
assist the collection management procedures. The following 
files should comprise the MIC: (1) Intelligence Collection 

Agent (ICA) file which will identify each collection agency 
and its available collection means; (2) Intelligence Collection 
Characteristics (ICC) file which will contain the range and 
degree of coverage for each collection means; (3) Intelli- 
gence Collection Requirements (ICR) file which will contain 
data specifying the information needed and reporting criteria; 
(4) Intelligence Collection Tasking (ICT) file which will 
identify the specific tasking requirements assigned to each 
agency . 

c. Named Area of Interest (NAI) 

The NAI should be a process which will provide 
users the capability of assigning a name to a geographical 
point, line or area (circle) . This will permit the user in 
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future queries or searches against that area to refer to it 
by the given name instead of inputting several strings of 
coordinates. Named areas of interest will be normally estab- 
lished by echelons having the requirement to retrieve data 
on given parameters. 

d. Staff Working File (SWF) 

The SWF should provide the staff member-user with 
the capability to enter, process, store and retrieve data 
which does not logically fit into other SACS files. It will 
provide the user the ability to create new files to meet new 
or changing conditions. 

e. Terrain File (TF) 

The TF should contain terrain characteristics 
and the results of terrain analysis in terms of tactical 
evaluation, that is, critical terrain, obstacles, observation 
traf f icability , and cover and concealment. This data will be 
available to all SACS users and will be graphic displays to 
supplement or highlight the map backgrounds. The terrain 
data will be provided by the topographical department. Staff 
members-users would add other data to supplement the file. 

f. Weather File (WF) 

The WF should contain weather characteristics and 
the results of weather analysis in terms of the weather impact 
on the operations. This data will be available to all SACS 
users and will be textual displays. The weather data will be 
provided by the meterological department. 
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g. On Line Query System (OQS) 

The OQS should be a retrieval language which must 
provide the SACS user with the capability to define retrieval 
parameters and report output formats. Retrieval parameters 
will be specified in terms of field identifiers, relational 
operators, and data values. Print and display commands should 
specify the output media and format. The user should be able 
to sort the output, sum numeric quantities, count the number 
of records meeting search criteria, and perform periodical 
summaries . 

h. Center to Center Communications (CCC) 

The CCC process should permit correspondence 
between LMC central processors of dependent LAFs . Messages, 
summaries, and processed reports could be dispatched or re- 
quested. The requirements for passing information from the 
lower LAF to the higher headquarters would normally be estab- 
lished by directive. 

4 . The Training Support Software 

It is logical to assume that the LAF in garrison would 
want to use SACS in a training capacity. To be able to accom- 
plish training, SACS should contain a training support package 
which can be used to satisfy a variety of training needs like 
the command post exercises, component training exercises, 

LAF's software checkout, and operational readiness evaluations. 
To satisfy these needs, the training support software should 
contain the following items. 
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a. The Simulation Package 

The basic design of the simulation should be able 
to accommodate two or more LAFs exercising in their superior 
LAF environment, a LAF exercising by itself, or the LAF ' s 
staff training by itself. The simulation package must permit 
battle simulation in a detailed event-sequenced logic and in 
an interactive way. This package also should provide realis- 
tic insights into the intelligence information processing and 
decision making on the modern battlefield. 

b. The Data Reduction Program 

The data reduction program should be used to screen 
the log tapes and extract the mission essential elements of 
analysis for the particular mission being conducted. Through 
analysis support, this data could be refined, analyzed, and 
assembled in appropriate feedback form for presentation to the 
participating staff personnel. The data reduction could be 
designed so as to be used during software checkout to assure 
operators that the operating system is performing up to speci- 
fications. Support algorithms could also be included to pro- 
vide the capability of trend analysis, comparative analysis, 
and to measure overall system performance , 

c. On-Console Training Program 

The on-console training program should be loaded 
on SACS and used for training of the respective staff personnel 
in performance of their operational responsibilities. An 
embedded training program should also provide evaluation of 
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the results of the training and maintenance of training con- 
duct records . 

5 . Software Distribution Matrix 

The distribution matrix should permit the automatic 
distribution of SACS messages based on specified message 
characteristics. A message originator must designate the 
message addressees either by entering the code name for each 
desired addressee or by entering a single value code that 
represents a discrete operator-created distribution list of 
addressees . 
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Figure 2.2s SACS HW Configuration. 
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Figure 2. 4: Operations Workstation. 
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III. WORKING WITH THE SACS [1,4] 



A. PERSONNEL FUNCTIONS 

The personnel functions will be performed from the corres- 
ponding workstation. The basic capabilities of data exchange, 
data management and simple graphic displays will be available 
to support the function. The personnel functions will have 
restricted use of SACS because only a few of them are tactical 
in nature . 

B. INTELLIGENCE FUNCTIONS 

The intelligence functions will be performed from the 
corresponding workstation. The capabilities of data exchange, 
data management, analysis assistance, interface with detection 
systems and color graphic displays will be available to sup- 
port the function. The new workstation will be used to re- 
ceive combat information and intelligence messages, retrieve 
LMC and/or GESS graphic displays and digital data requested 
by the chief of staff, and to retrieve and manipulate SACS 
data for evaluating, analyzing and interpreting combat infor- 
mation. Most coordination within the LAF ' s comman post should 
be accomplished verbally or by using hard-copied outputs be- 
cause this form of communication is most efficient because of 
the close proximity of the staff personnel. Control of the 
content of analysis product files should be under the intelli- 
gence subsystem to avoid confusion and possible contradictions. 
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Within the LAF command post the intelligence functions 
are performed by several staff sections. The intelligence 
operations functions will use SACS primarily to be on line 
with the current tactical situation and terrain data from the 
corresponding files. Also supervising intelligence dissemina- 
tion, coordinating the intelligence collection assets, and 
determining intelligence needs will require access to LMF 
and GESS graphic displays and file data. Preparation of the 
intelligence annex and the formal staff briefings will require 
the creation of graphic displays as well as the gathering of 
current situation data. The intelligence analysis and produc- 
tion function will be performed using every SACS capability. 
SACS will be used to store combat information. Maneuver units, 
collection agencies and detection systems will be able to 
enter combat information directly into the SACS enemy situation 
files. The SACS features of query, filtering and correlation 
will be used to confirm, correlate and organize the combat 
intelligence into a form suitable for tactical analysis. The 
terrain and weather data will be used to create graphics dis- 
plays showing key terrain, obstacles, observation and firing 
abilities, cover and concealment, accompanied with weather 
impact texts. This data augmented with those of the enem.y 
order of battle, can be used to determine possible avenues of 
enemy approach. This data also will have utility in develop- 
ing plans of action and tactical maneuvers, and for logistics 
subsystem in developing supplying routes and locating depots. 
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The enemy order of the battle analysis will be elaborated 
using SACS. Enemy situation data will be used for determining 
enemy unit identification, composition, disposition and strength. 
The current enemy order of the battle can be compared with the 
corresponding past records to determine and display unit 
identifications, enemy units arrangement, enemy unit disposi- 
tion and enemy's course of action. 

The enemy situation, order of battle and terrain files 
will require management. Historical records and terrain and 
weather features in the LAF ' s area that are no longer needed 
will be deleted. The enemy situation file can grow larger 
than any other file and it must be closely supervised to avoid 
system overloads. The necessary deletions can be automatically 
done, based on the criterion of age. Threshold indicators 
must indicate the critical file size and must initiate an 
automatic file pruning to maintain an acceptable file size 
without ignoring the usefulness and the meaningfulness of 
the file contents. 

The intelligence reconnaissance and surveillance function 
will use the SACS to process requests for preplanned recon- 
naissance flights and to monitor the ground reconnaissance 
and surveillance activities. 

The security functions will use SACS to receive intelli- 
gence collection tasking messages which will be translated 
into specific signal intelligence indicators to be used in 
tasking army security agency field teams. The signal security 
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function involves monitoring friendly non-secure communications 
to ascertain what information is being passed that might be 
of use to the enemy. SACS communications must be over secure 
channels which will not be subject to monitoring. 

Figure 3.1 presents a gross data flow diagram for the 
intelligence subsystem using SACS. 

C . OPERATIONS FUNCTIONS 

The operations functions will be performed from the corres- 
ponding workstation. The capabilities of data exchange, data 
management, analysis assistance, color graphic displays and 
war games for training, will be available to support the func- 
tion. The new workstation will be used in developing the 
friendly situation, unit status, tactical estimate, maneuver- 
ing forces control, and supervision of operations in compliance 
with the General's decisions. The overall LAF ' s operational 
status will be developed, stored and displayed and/or printed 
on demand. Tasks organization for supporting the maneuvering 
forces should be extracted, presented and reviewed as part of 
the operational status. The SACS database will be used to 
assemble an overall operations estimate for the Commanding 
General . The input sources for developing this estimate will 
be the enemy situation information as they have been filtered, 
evaluated, and correlated by the intelligence subsystem; the 
battlefield information about the friendly forces as they will 
be submitted in periodical reports by the siabordinate echelons 
of the LAF; other information arriving from other friendly 
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sources as the superior or adjacent LAF . All this data must be 
logically augmented by the existing relevant database, in 
displays and/or hardcopies. Free text summaries must be 
added to explain the graphical presentations and both graphics 
and displays will form the operations estimate required by 
the General. Supportive courses of action can also be pre- 
pared and presented along with the estimate. The course of 
action should include: the type of action to be taken, time 

the action will begin, location of the action, use of the 
available means and purpose of the action. Changing tactical 
requirements needed to support the maneuvering plan, task 
organization, fire and engineering support will be detected 
by monitoring of the superior LAF networks and SACS situational 
displays. As tactical changes are identified, they need to 
be assessed in terms of criticality and developed into appro- 
priate courses of action. Approved plans must be formed into 
orders, modified operations overlays, and updated SACS files 
necessary to implement the approved plan. 

The operations subsystem tactical planners must use its 
workstation to develop on consoles, future courses of action 
to satisfy the General's guidance. Graphically developed 
courses of action may be assembled and stored in planning 
files and briefed to the General using the LDP console. 
Graphical and textual compositions will be invaluable in 
generating and storing courses of LAF ' s action to different 
tactical situations. Here it must be remembered that 



47 



unforeseen enemy action can decoordinate the LAF. The above 
composition will prevent such an undesirable situation and it 
will contribute to the stability of the system (LAF) . 

Operations subsystem will use its workstation to maintain 
the current estimate by quering and establishing information 
requests against the database. Assemb)led data can be organized 
graphically to demonstrate enemy and friend frontlines, boun- 
daries of echelons, command posts and tactical maneuvering 
positions, barriers and obstacles, nuclear and chemical strikes. 

Preplanned air support requests should be processed using 
the staff working file. The air support planning will be helped 
considerably by the displays on the LDP of the detection sys- 
tems, display's graphical and textual information about the 
air tactical situation, giving the target itself; route, 
height, and speed of flight; identification of friend, foe, 
unknown, etc. This way the planner will have complete and 
precise information on how much an echelon or area suffers from 
enemy air force attacks, a fact which is of high importance 
in planning air support requests. 

Figure 3.2 presents a gross data flow diagram for the 
operations subsystem using SACS. 

D. LOGISTICS FUNCTIONS 

The logistics functions will be performed from the corres- 
ponding workstation. The capabilities of data exchange, data 
management, analysis assistance and graphic displays will be 
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available to support the functions. The system graphics will 
be used to form the displays and hardcopies of significant 
logistical events for briefing the General. These displays 
showing obstacles, key terrain, roads, rivers, air strips, 
friendly and enemy unit locations, will be used to determine 
the main supply route and supply points. Once developed, all 
this information will be stored in SACS files for future 
reference. Area damage control, maintaining the status of 
supplies, vehicles, and equipment necessary for the accomplish- 
ment of the mission will be handled using SACS. Data will be 
gathered and organized by SACS and algorithms will be provided 
to perform the statistical analysis requirements of logistics. 
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IV. SECURITY AND SACS [6,7,8] 



A. SACS SECURITY INTO PERSPECTIVE 

Computer fraud and abuse in the private sector creates 
newspaper headlines since these crimes usually involve large 
amounts of money. But analogous crimes in a military system 
(e.g., SACS) may go completely undetected, even though the 
potential for damage to the national security is much more 
serious. The reason for this lack of detection is that when 
information is leaked electronically it does not disappear; 
the original remains intact and unaltered and there may be 
no evidence that it has been copied. 

Computer systems have not been very good at keeping secrets. 
It is too easy to demonstrate that an opponent can penetrate 
the protection mechanism of typical operating systems, gain 
control of the machine, and obtain any information he wishes. 

The only reliable approach is to prevent an opponent from 
gaining access to the computer system. This can be typically 
accomplished by locking up the computers and clearing all the 
people who use them to the level of the most sensitive data 
on the machine. This approach is at least inconvenient. 
Operational problems occur when information cannot be made 
available quickly to users who need it because of too tight 
restrictions on access to the system. For this reason, several 
models of computer security have been developed in the past 
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which must be the milestone concepts in SACS security. These 
concepts are briefly discussed below. 

1 . Basic Security Condition 

The basic security condition has to restrict a user 
from reading information classified above his clearance. Thus 
the system must keep track of the levels and compartments 
associated with the files used by a job during a session. 
Whenever a new file is created, it must be marked with the 
appropriate security level and all the compartments of the 
file used so far. Only certain authorized users will be able 
to access information of a corresponding classification level. 

2 . Access Matrix 

The access matrix has to describe the system in terms 
of its subjects and objects. Subjects are usually processes 
operating at the direction of a user. Objects are files and 
the kinds of access that subjects may have to files. Sub- 
jects will be listed as the rows of a matrix and the objects 
as its columns, so each entry of the matrix tells what access 
a subject is allowed to an object. 

3 . Security Kernel 

The security kernel exploits the concept of a "reference 
monitor" as a basis for developing a secure operating system. 

The reference monitor would check each reference by a subject 
to an object and be sure that it is authorized by the access 
matrix. The mechanism that handles the reference monitor has 
to be tamperproof, invoked on every reference, and subjected 
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to complete analysis and test. The security kernel of the 
SACS must be composed of its reference validation mechanism, 
access control, security-related functions and nothing else. 

Two axioms m.ust govern the security kernel concept: (a) No 

user may read information classified above his clearance, 
and (b) No user may lower the classification of information 
(no "Read Up," no "Write Down") . 

B. SECURITY AND THE LIFE CYCLE OF SACS 

For a developer embarking on a new project that requires 
a system like SACS to restrict some of its information from 
some of its users, there still is no approach that guarantees 
absolute success. To assume invulnerability of SACS as a 
result of a good security program is like assuming that a car 
will never run out of gas because it has a gas gauge. However, 
a good security program is a necessity and there are at least 
three doctrines for the SACS developer who faces the need to 
separate computer users with different clearances and data 
with different classifications. These three most significant 
doctrines are strongly related to the SACS life cycle. 

1 . Security and the Study Phase 

The security requirements of the SACS must be con- 
sidered together with its functional requirements. Security 
is not something that can be added to an existing design even 
though often security seems separate from function. The 
intelligence subsystem must, for example, deliver tactical 
information, and security imposes the constraint that certain 
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parts must not be delivered to the logistics subsystem. It 
is tempting to divorce the function from the constraint. 

Viewed at the top level, however, the requirement is for a 
system that delivers the intelligence information in a way 
that does not compromise it. Security requirements can 
affect the entire structure of the SACS software and thus needs 
to be considered at the highest level of design. 

2 . Security Throughout the Design and Development Phase 
It is crucial to identify and state the security re- 
quirements clearly. But it is still necessary to pay close 
attention to the techniques used in designing and building 
the SACS. The functions of the SACS must be studied, focusing 
on the requirements for the flow of classified information, 
and on the conditions under which classified information is 
to be disclosed, modified, reclassified or to enter or leave 
the SACS. The first step can be a simple informal but precise 
model of the information flow and authority in the SACS. Such 
a model could help both developers and users in understanding 
what is to be enforced. The second step must be the use of 
hierarchical specifications for the design. A top level 
specification that will reflect the SACS structure and infor- 
mation flow, as well as a program specification to allow 
personnel to review and assess the information flow and 
authorization mechanisms, should be included in these hierachi- 
cal specifications. The third step must be the choice of 
hardware that reduces security problems. Generally hardware 
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should provide good mechanisms for isolating different compu- 
tations, simple and efficient ways to control the flow of 
information between isolated contexts, and a uniform way of 
treating different kinds of objects (e.g., SACS files) . 

Features such as virtual memory, a device interface that 
offers the possibility of a uniform treatment of memory, and 
the ability to change addressing contexts rapidly will help 
in the implementation of a secure SACS. Several machine 
states that restrict access to critical portions of the instruc- 
tion set are not required if all accesses to data are mediated 
by the virtual memory mechanism, but they should be used as 
another way of protecting critical operating system data, for 
example the contents of the mapping registers. The fourth 
step must be the choice of programming languages for which 
there exists a reliable and well verified compiler. The final 
step must be the construction of test plans with specific 
attention to the security requirements of the system. Testing 
is an important way of establishing confidence that the con- 
trols implemented are in fact effective. 

3 . Security and Software Engineering Techniques 

Systems like SACS that must enforce military security 
often have a requirement that others lack. Not only must the 
builder and the user be satisfied with the correct functioning 
of the system, but it must be possible to convince the certi- 
fying agent that this is in fact the case. This consideration 
makes it imperative that the software be designed, implemented, 
and documented according to software engineering principles. 
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C. SURVIVABILITY OF THE SACS 



One very important feature which must characterize SACS is 
its survivability after a possible component failure. It is 
easily understood how destructive the unavailability of SACS 
would be in a case where the tactical situation does not permit 
a rapid switching to the manual system. So one criterion for 
designing a highly secure SACS is to ensure its continued 
reliable operation and availability. A survivable SACS should 
provide for "grateful degradation; " a SACS with failed com- 
ponents should continue to provide service even at reduced 
levels. A survivable SACS should be designed so that a failed 
component could be taken off-line, repaired and placed back 
on-line, all while the system should provide uninterrupted 
service. One key for SACs survivability must be "redundancy." 
If a component fails, then an equivalent component must pick 
up the slack. Multiprocessing will be im.portant in any 
survivable SACS. Other features which should be considered 
in order to achieve survivability of SACS are: 

1. Incorporation of fail-safe mechanisms into the firmware 
rather than in software 

2. Use of transparent multiprocessing; this allows perfor- 
mance upgrades without software modifications 

3. Use of multiple input/output subsystems 

4 . Incorporation of major portions of the operating system 
into hardware 

5. Incorporation of fault detection mechanisms into the 
hardware and software. 
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D. NETWORKING THE SACS WITH SECURITY 



It has been stated in Chapter II that a SACS is expected 
to exchange data with other tactical data systems. This ex- 
pectation can be met by networking the SACSs of related LAFs 
using the packet switching technique. The means for attaining 
security in the packet switched communications system is the 
concept of the end-to-end encryption. An end-to-end encryp- 
tion is an apparent need in order to protect the exchanged 
information since all the exchanged messages will be out of 
the physical control of the communicators. In an end-to-end 
encryption, the sender encrypts the message and it remains 
encrypted while being transmitted through a network until it 
is received and decrypted by the receiver. A device called 
a PLI (private line interface) should be placed between the 
host LMC and the packet switches as it is shown in Figure 4.1. 
Figure 4.2 shows the PLI layout. The PLI will encrypt the 
data in each packet, leaving the header in the clear. The 
switches will route the packets, but the actual data will be 
encrypted. As a result, when packets will pass throught 
the switches, operators will not be able to examine the data 
in encrypted form nor will misrouted packets be able to divulge 
classified data. All the switches must be placed in military 
sites and can be manned by the same cleared personnel who 
maintain the SACS. The encryption devices will be keyed by 
using the same keys for a user community and different keys 
for other communities; in this way the communications system 
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The 



will be partitioned into "communities of interest." 
maintenance of the switches can be performed by the operators 
of the nearest SACS being interconnected. The switches 
themselves are computers quite small and inexpensive, and about 
as complicated as a peripheral controller. Since the tech- 
nology and complexity is about that of a small piece of digital 
gear, the additional maintenance load on the SACS operators 
will be quite small. The PLIs can be collocated with the 
SACS terminals, or if multiplexers or concentrators are used, 
the PLIs can be placed at the access point to the switch, 
provided that multiplexers and concentrators are multilevel- 
secure and that the terminals are all secure as needed. 
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V. FACING THE END USER PROBLEM [7,9,10,11] 



A. THE END USERS OF THE SACS 

When SACS is introduced, it will be necessary that cer- 
tain principles of automated systems should be understood by 
the LAF commander, staff members and other end users who will 
be affected by it. To a large extent success or disappoint- 
ment is dependent on these end users, their involvement in 
the definition and logical modeling of the data, their employ- 
ment of end-user database language and their acceptance of the 
results and the principle of shared data. 

The term "end user" is used to describe someone who inter- 
acts with a computer in one way or another. This term is too 
broad and covers an enormous range of skills and, unless it 
is further qualified, may be used to describe almost anyone 
in the LAF that will use the SACS in some kind of data proces- 
sing. It is worth listing the ways in which a person may be 
considered an end user. 

1 . The Recipient of Regular SACS-Generated Reports 

Nearly everyone connected with some form of automatic 
data processing uses such forms. Frequently these reports are 
adequate to the needs of the reader. However, it is often 
the case that hours are wasted in performing simple analyses 
that could easily have been performed by the program that 
generated that report. 
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2 . Application Programmers 



Although there would appear to be no limit to the 
ability of an application programmer to obtain the desired 
data, this is frequently not the case. An application pro- 
grammer, because of the amount of technical programming detail 
that must be mastered, is frequently "locked" into one system; 
a computer, programming language or operating system. A lack 
of understanding between the applications programmer and the 
person who uses his results is a major cause of frustration 
and delays. 

3 . Users of Interactive Database Query Languages 

Such users will be the majority of the SACS' users. 
Their ability to extract the data they want will be limited 
by the power of the query language and their skill at using 
it. The problem is that there is no standard query language 
and such users may have to learn different languages — something 
that could be avoided. This is the main topic of this chapter. 
The use of a good general-purpose database query language 
will be of general benefit because it will be easy for naive 
end users to learn, and because it will provide the rapid 
access to data and quick writing of application programs that 
these users require. 

B. THE QUERY LANUAGE 

A mistake that is frequently made is to confuse the com- 
plexity of a language with its power. If the power of a 
language refers to its ability to control the hardware on which 
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it is run, this confusion may be justified because the current 
hardware is inherently complicated. However if power means 
the ability to provide an abstract description of a compu- 
tational process, there is no reason that this should entail 
a language with complicated syntax or constructs. LISP and 
PROLOG may not be the ideal languages for end users in the LAF 
community, but they are among the most powerful (in the second 
sense) and there aren't languages with a simpler syntax. 

Database access languages may be broadly divided into those 
that are powerful but difficult to learn, and those that are 
limited but easy to learn. However there is a non-procedural 
(so very easy to learn) query language which is quite power- 
ful also. This is Query-By-Example (QBE) which is associated 
with the relational database model. 

It is desirable that the staff member (being generally a 
naive user) approaching a terminal should be required to know 
as little as possible in order to get started. He may have to 
know a little more in order to use the subtleties of a language, 
but this also should be minimized. He may approach a database 
knowing very little about the names of the records, of fields 
(attributes) , or how to access them. The best means of ex- 
plaining the user language functions is by examples. Various 
psychological studies of QBE have shown that naive users acquire 
the skill to make complicated queries in less than three hours. 
The language is designed with the excellent principle that 
the thinking process the user follows is the same as he would 
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use to find the same information without a computer. More- 
over, the effectiveness of QBE will never disappoint a staff 
member who happens to know a lot about computers and database.^ 
There are certain extensions of QBE like the QBPE (Query 
by Picture Example) that could be extremely useful for staff 
members if they want to create graphs with map areas such as 
the maneuver plans for example. Another extension of QBE 
is the PBE (Procedures by Example) which covers a wide area 
of SACS applications. QBPE is based on an integrated database 
system interfaced with an image analysis system. By using 
pattern recognition and image processing manipulation func- 
tions, pictorial descriptions can be extracted from images. 

These extracted descriptions and inherent registrations of 
pictures are then integrated into a relational database; the 
original two-dimensional pictures are kept in a separate picture 
store. Thus, queries concerning pictures can be manipulated 
through the relational database, eliminating the need to 
process vast amounts of imagery data. If a user's request 
can be expressed in terms of the extracted picture descrip- 
tions, there is no need to retrieve and process the original 
pictures. If, on the other hand, the stored information is 
not sufficient, all pictures satisfying selection criteria can 



5 

J. Oilman in his book Data Base Principles , CSP 1982, 
pp. 207-208, proves the power of QBE. 

f: 

J. Martin, in his book An End User Guide to Data Base , 
1983, pp. 99-101, presents 170 lines of a COBOL program for 
an inquiry that can be handled with one screen by QBE. 
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be retrieved from the picture store and processed until the 
required precision is obtained. Figure 5.1 presents the data- 
flow diagram of the QBPE background. Using QBPE is the SACS, 
most queries could be specified from relations which will be 
parts of a database comprised of land images and digitized 
maps. In Office Procedures by Example (OPBE) there are 
primarily four major components beyond the QBE database manage- 
ment system, some of which are generalizations of the QBE 
facilities . 

1 . Generalized Data Objects 

Whereas the fundamental data object in QBE is a table, 
in OPBE the objects are forms, reports, charts and documents, 
all of which can be created, edited and sent to other nodes 
of the system. 

2 . Communication Subsystem 

In order to communicate in the form of the above 
described objects to various nodes of the system (such as the 
related LAFs being connected through a network) , we must have 
a communication subsystem. For each node of the network there 
exists a local database with the ability to access centrally 
shared databases. 

3 . Triggers 

A basic necessity in any office automation is the 
ability of the system to take automatic actions whenever 
certain conditions, times or events are met. In doing so the 
user can automate much of the routine procedures, thus devoting 
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his time to more advanced tasks. The following are some 
actions that we may want to automate: 

- Deferring of certain messages 
Creation of various logs 

Automatic inventory replenishment requests 
Follow-up procedures (for example if an answer is not 
received within 2 hours, the user will be alerted) . 

Complicated boolean and arithmetic operations can be 
formulated using the condition boxes of the OPBE & OBPE. 

The text processing in the OPBE is harder than that of 
incorporating arithmetic. This problem can be solved by a 
good interface between the QBE and a suitably structured 
editor . 

At the level of the user interface QBE is extremely 
well engineered, exploiting color graphics and screen control 
for ease of data entry. It leaves the user in no doubt about 
the data model (relational) that is in use; relations are 
visible tables. The programming environment, the means by 
which data and queries are stored and recalled, is also ex- 
tremely well thought out. 

C. THREE PROBLEM SOLVING SCENARIOS 

To show the utilization of the user communication interface 
in intelligence production, three trivial examples of using 
QBE and its extensions, are presented. The intention of the 
examples is to demonstrate to the staff members a typical 
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interaction session rather than to present truly valid algorithms 
for the corresponding procedures. 

1 . Identification of Missiles in a Firing Event 

The hypothetical problem of the missile event can be 
described as: 

a. Identify the missile as a known configuration 

b. Identify the missile as a new system 

c. Produce a report of the parameters of the event. 

The data available about the event include: 

a. Launch Site: Rplace, USSR Missile Launch Facility 

b. RV Impact: Gplace, Greece 

c. 2 stage ignition: 

Altitude = 30 km over Bplace, Bulgaria 
- Time = . 4 hours 

The user sitting at the terminal is presented with 
a skeleton of a table on the screen: 

(Table Name) (Field Names) 




The user knows that there is a "MISSILE" record and he wants 
to know what field exists in that record. So he types: 



MISSILE P. 
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"P." stands for "Print." The terminal may respond increasing 
the number of columns as necessary: 



MISSILE 


CLASS 


TYPE 


STAGE 


RANGE 


RADIUS 















The user wants to know what missiles have two ignition 
stages, so he types: 



MISSILE 


CLASS 


TYPE 


STAGE 


RANGE 


RADIUS 




P. 


P . 


2 


P . 


P . 



The values of the fields are then listed in the corresponding 
columns : 



MISSILE 


CLASS 


TYPE 


STAGE 


RANGE 


RADIUS 






HlOl 




4500 


km 


17 


km 




SRBM 


HIOIJ 


2 


4000 


km 


17 


km 






D4 




2000 


km 


14 


km 






D5 




1500 


km 


12 


km 






DDEO 




1000 


km 


7 


km 



The user knows from his maps that the distance between Rplace 
and Gplace is 1500 km. So the information obtained so far is 
not enough since (5) gave four types of missiles of two igni- 
tion stages that could strike Gplace. It is clear that the 
user's query to identify the missile cannot be answered by 
reference to one type of record. With QBE he can display 
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two or more different skeletons on the screen at once. He 
fills in both of them and then presses the ENTER key (or 
equivalent) indicating that this is one entry. In our example, 
knowing the 2nd ignition altitude and time, he can call a 
second record having the trajectory elements of the missiles. 
Thus he combines the two records as follows: 



TRAJECTORY 


MTYPE 


TTYPE 


STAGE 


ALTITUDE 


TIME 




X 




2 


30 km 


.4 h 















( 6 ) 



MISSILE 


CLASS 


TYPE 


STAGE 


RANGE 


RADIUS 




P. 


X P . 


2 


P . 


P . 



The terminal will respond: 



MISSILE 


CLASS 


TYPE 


STAGE 


RANGE 


RADIUS 




SRBM^ 


D4 


2 


2000 km 


14 km 



Now the user's query has been answered after following a 
very simple procedure. 

Suppose that instead of (5) , we had the (5') listing: 



MISSILE 


CLASS 


TYPE 


STAGE 


RANGE 


RADIUS 




NULL 


NULL 


2 


NULL 


NULL 



SRBM = Short Range 



Ballistic Missile 
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In this case the user could insert the new system as follows: 



TRAJECTORY 


MTYPE 


TTYPE 


STAGE 


ALTITUDE 


TIME 


I . 


NEW 


7 


2 


30 km 


.4 h 



( 6 ') 



MISSILE 


CLASS 


TYPE 


STAGE 


RANGE 


RADIUS 


I . 


UNKNOWN 


NEW 


2 


1500 + 


7 



"I." is used for insertions. In this last case, the user 
inserts the data he has with respect to this new system. In 
the columns, he has no data, so he inserts the words "UNKNOWN," 
"NEW," "1500+," "?." When he obtains additional information 
he can update the records as follows ("U." is used for update) . 



TRAJECTORY 


MTYPE 


TTYPE 


STAGE 


ALTITUDE 


TIME 


U. 


D4 


PARABOLA 


2 


30 km 


.4 h 



(7') 



MISSILE 


CLASS 


TYPE 


STAGE 


RANGE 


RADIUS 


U. 


SRBM 


D4 


2 


2000 km 


14 km 



Using QBE the user can also delete data ("D.") , link tables, 
retrieve data under conditions specified by him. The database 
administrator can assign authorizations to certain users and 
he can also impose constraints. These control and integrity 
features of QBE are very desirable in the SACS case, and they 
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can be elaborated in accordance with the SACS security general 
fame . 

2 . Creation of a Graph of the LAF ' s Vital Area 



The TAC using the QBPE facilities can read its color 

map background which can be stored in a digital form in a 

separate picture store. Most queries would be specified from 

8 

the following relations: 

CITIES (FRAME , CITY-lD, XI , X2 , Yl , Y2 ) 

CITYNAME (FRAME, CITY-ID, NAME) 

ROAD (FRAME, RO-ID, XA,XB,YA,YB) 

RO-NAME (FRAME, RO-ID, NAME) 

MOUNTAIN ( FRAME, MO UN-1 D, XMl ,XM2 ,XM3,XM4 ,YM1,YM2 ,YM3,YM4) 



etc. including all the necessary information for the 
production land features. X and Y describe the required 
corresponding 2D coordinates. The "FRAME" is represented 
by a number that corresponds to a certain portion of the 
original map image. 

Suppose the user wants to sketch the vital area within 
certain boundaries specified by the land features. This query 
can be formulated as follows: 



MOUNTAIN 


FRAME 


MOUN-ID 


NAME 




2 


0£ 


OLYMPOS 




3 


0^ 


OSSA 




7 


il 


AIMOS 



g 

For a complete analysis of the concept, see: "Picture 

Query Languages for Pictorial DB Systems," by N.S. Chang and 
K.S. Fu, Computer , November 1981, pp . 23-33. 
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MOUNTAIN 


FRAME 


MDUN-ID 


XMl 


XM2 


XM3 


XM4 


YMl 


YM2 


YM3 


YM4 




2 


04 


a 


9 


q 


i 


d 


1 


u 


X 




3 


09 


b 


h 


r 


i 


e 


m 


V 


z 




7 


n 


c 


k 


s 


o 


f 


n 


w 


z 



The system will respond with an intermediate result table for 
all the boundary segments of the vital area: 



R1 


XI 


Y1 


• • • 


XN 


YN 




X 


Y 


• • • 


Z 


W 















The user wants to draw the roads which are in the vital area: 



ROAD 


FRAME 


RO-lD 


NAME 




2 




ETHNIKI 




3 


11 


EGNATIA 




4 


62 


LARISSAS 



The command "S." stands for "Sketch" so the user will type 
"S." in (10) and (11) as follows; 



R1 


XI 


Y1 


« • * 


XN 


YN 


S . 


X 


Y 


• • • 


Z 


W 















ROAD 


FRAME 


RO-ID 


NAME 


S . 


2 


12 


ETHNIKI 




3 


li 


EGNATIA 




4 




LARISSAS 
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The system will respond presenting on the screen the sketch- 
picture of the vital area with the specified roads. The user 
could ask for the drawing of the rivers, hills etc., according 
to his need. The user exploiting the other graphic capabili- 
ties of the TAG can enrich his sketch by drawing friendly and 
enemy dispositions, avenues of approach, points of interest, 
etc., and by adding textual explanations for his reports. 

Currently the pictorial operators used to contrast 
pictorial entities are as listed below: 

Pictorial Union of two given regions: UNI0N-R1R2 

Pictorial Intersection of two given regions : INT-R1R2 

Compute the length of a given line: LENGTH-L 

Compute the perimeter of a given region: LENGTH-R 

Compute the area of a given region: AREA-R 

These operators are intended to construct only the basic 
relations among points, lines and regions for queries concern- 
ing pictorial information. Depending on the application re- 
quirements, user-supplied operators can be implemented for 
more efficient operation. 

3 . Sending A Message to the Superior LAE/G3 

Suppose that the G3 of our LAF wants to send the 
maneuvering plan for approval to the superior LAE. This can be 

9 

done using the capabilities of OPBE as follows. 



9 

See "A Language for Office & Business Automation" by 
M. Zloof, Office Automation Conference Digest , March, 1980, 
pp. 240-260. 
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UNIT 


NAME 


LOCATION 


SENDER 






L 













A 






NAME: G3 

LOCATION: 


L 


Subject : 


Maneuvering Plan 






- - - (TEXT) ------------- 




SEND A,B to G3 



Everything presented here in plain English could have been 
encrypted . 

After presenting the new work stations to the staff 
members and after explaining some of the important user 
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communication concepts, they will quickly perceive the advan- 
tages of SACS; nearly all the information resources they 
might require are readily available from their work station. 
They will be able to retrieve documents that relate to their 
job and insert relevant analysis products in their reports. 
They will be able to generate messages and on-line reports for 
those who need to use the results of their work. They will 
have convenient facilities for presenting and routing on-line 
requirements for additional information collection. 

Whereas the staff member will be in the beginning 
mildly amazed with the versatility he has observed in the 
workstation equipment, he will soon experience the potential 
of the new horizons offered by a friendly, trustworthy and 
obedient SACS for carrying on his tasks. 
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VI. INTELLIGENCE INFERENCE AND DECISION MAKING [13] 



A. THE MILITARY INTELLIGENCE PROBLEM 

It is clear that every staff activity in the LAF is ex- 
clusively based on the intelligence subsystem during the 
war time. The operations and logistics plans are formed using 
the timely evaluated information about the enemy's location, 
strength, capability, vulnerability and intentions. If this 
information is accurate then we can make good, more or less, 
plans. But if the information we have is not accurate enough, 
then it is not possible to make good plans and good decisions, 
no matter how good staff officers or inspired leaders that 
we have. The old characterization of Clausewitz seems to 
still be appropriate: "...a great part of the information 

obtained in war is contradictory, a greater part is false, 
and by far the greatest part somewhat doubtful." Modern 
improvements in intelligence sensors have almost embarrassingly 
exploded the amount of data collected, but the information 
is still enormously variable — mainly because this advance in 
sensor technology has been countered by enemy concealment 
and deception sophistication. The intelligence expert cannot 
know the location, activity and intention of every unit in 
the enemy army, but if enough is located the rest must be 
inferred. The theoretical question is--how much he has to 
know to be able to infer the rest? 
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A LAF has many sources of data. There are the forward 
units, observers, and patrols reporting enemy type, activity 
and strength. Prisoner interrogation and agents are another 
source. There are radio intercepts, visual, magnetic-acoustic 
and radar sensors associated with all LAFs. The use of 
aircraft, overflying the enemy, generates another avalanche 
of data. The intelligence analyst must look for signals in 
the presence of noise or deception. Camouflage netting for 
example tends to obscure the size, shape and color of covered 
objects from visual observation. The analyst must expand his 
examination to consider reports of other activities that may 
be germane to the event of interest. A report of an armored 
brigade in the area, for example, might give support to the 
belief that an object under camouflage is a tank. There is 
the occurrence of frequent transformation between the detec- 
tion of any event and the final assessment. Figure 6.1 pre- 
sents this sequence. The first transformation (P^ occurs 
as some sensor detects physical stimuli received from a 
special characteristic of the target. The second transfor- 
mation (P ) takes place as the interpreter perceiving the 
size and shape may report possibly one armored vehicle. The 

third transformation (P ) may identify it as a tank; the fourth 

s 

(P^) the model and type of tanks in the force. The fifth 
(P^_j_j^) transformation might be the identification of the 
force as the "X" Armored Division commanded by General "Y" . 

If the enemy strategically places tank silhouettes to give 
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the illusion that tanks are present, a whole series of errors 
can result. On the other hand, the expansion of the probability 
trees for the enormous numbers of events we will have from the 
sensors will make the use of SACS a brute force approach, 
inevitably prone to combinatorial explosion if methodologies 
are not applied to establish the basis for the design of an 
appropriate data processing system for military intelligence 
purposes. Thus the objective of this chapter is to develop 
some mathematical models that: 

Can minimize the harmful effects of incomplete and 
unreliable data. 

Can facilitate the information inference from the 
existing data. 

- Can be the basis of further research for a better 
simulation of the intelligence problems. 

B. THE TACTICAL INTELLIGENCE MODEL 

Suppose there is a critical flank which must be held. 

Let X and Y represent the level of forces on each side. The 
value of X should be proportional to the value of Y since this 
is imposed by the tactic doctrines. In addition, the change 
of X force, because of casualties, is proportional to the 
absolute size of the opposing force. These relations can be 
expressed by the following equations: 

X = k^Y 

X- = k^Y 
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If we add these equations we'll have: 



X + X' = (k^ + k^) • Y 

If we say that k^^ + k^ = k, then: 

X + X’ = k-Y or 
X' = k-Y - X 

This equation assumes perfect information of X about Y. If 
X is not sure of Y force level and has to estimate or infer 
from intelligence (this is often the case) , this equation 
can still be used by using estimate terms involving the mean 
(y) and variance (a) 

X's estimate = Y (y ) 

e ^y y 



Then 



X' = k- [Y (y ,a ) ] - X 

e y y 



We can go further and enrich the equations with 
land morphology, weather impact, etc., in order 
more representative model . Finally the general 
equation will be: 



factors of 
to make a 
form of this 



X' = f (X,Y,Z, . . . ) 
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We can write a FORTRAN program to find approximate 
solution to this first order differential equation with 
initial condition X (Y =0) =0, using Euler's method. Euler's 
method assumes that during the interval [Y,Y+AY) , X' remains 
constant and that 

AX/AY = X' = f(X,Y) 

^ AX = AY-f (X,Y) . 



Thus 



X, 



New 



= X 



Old 



+ AX = X 



Old 






Or stating this as a difference equation: 



X 



i+1 



X. + AY- (X. ,Y . ) 
1 11 



( 1 ) 



for i = 0,1, ...,N. The FORTRAN program is: 



READ N, DELTAY, Y, X 
PRINT, X,Y 
DO 10 I = 1,N 
Y = Y + DELTAY 
C Use equation (1) 

X = X + DELTAY * F(X,Y) 
PRINT, X,Y 
10 CONTINUE 
STOP 
END 



The change of Y in discrete units 1,...,N expresses the rein- 
forcements of Y in terms of, say, battalions. Of course 
F(X,Y) = f(X,Y) must be defined in a FUNCTION subprogram. 
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For a fixed value of we can have an error which increases 

2 

as AY increases and is of the order of (AY) . 

It must be stated here that there is a bias against y and 
a for this kind of problems. In the following picture, the 
solid and dotted distribution have the same y and a. However 
there is a question if they would be treated the same. 

I 




In addition, another question, equally reasonable, is how 
representative are monotonic functions in expressing the 
dynamics of the critical flank. In any case this model is 
very tractable analytically and there are a lot of things 
that could be done in this vein. 

C. THE TARGET DETECTION MODEL 

Suppose we detected a group of enemy targets with a low 
resolution radar sensor. The display shows just "blobs." 

The question is, "Are they tanks or artillery, or some mix- 
ture of both?" We decide to make four trials with another 
high resolution sensor to identify each one of the four 
"blobs." If our awareness or indifference is such that it is 
equally likely that they are tanks or artillery. Figure 6.2 
shows there are 16 possible outcomes to the four trials. 
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Suppose the results of the first three independent trials 
were "tank, artillery, tank." To the question, "What is 
the possibility that the fourth try is a tank?", the answer 
is 1/2. In other words, by considering the permutations of 
trials as the probability space, we can't learn anything. 
Instead of this from our knowledge of the enemy's organization, 
we can express our indifference by equal likelihood in terms 
of distributions, namely, that it could be eitehr 100% tanks, 
75% tanks, 50% tanks- 25% tanks or 0% tanks, and make them 
equal in probability (Figure 6.3) . Now if our experience 
on the first three trials was "tank, artillery, tank" then 
the probability of the fourth trial being a tank is 3/5 = .6. 

In other words, if we condition the probability space through 
the use of distribution of ratios, we learn more. 

D. THE "TWO LOOKS" MODEL 

The previous model assumes that there is a final sensor 
which makes the identification of tank and artillery decisive 
and correct. This is not usually the case. It is often 
necessary in identifying a target to make repeated trials 
and combine ancillary data with detection data. We can set up 
a decision theory model which will give us probabilistic 
limits involved in looking at the same target with multiple 
sensors. The question is, "What is the payoff for multiple 
sensors?", or, "If we make repeated trials with low quality 
sensors, do we in fact gain?" Or, "Shall we define a detec- 
tion as the union of two sensors or the intersection of two 
sensors? " 
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The analysis would be; 



Let 



p = "a priori" probability that a target is in 
the area 

= Probability to detect a target given that the 
target is present 

P = Probability to detect a target given that the 
target is not present. 



Then the probability of making a right decision is given by 
the equation; 



Pj, = p^-p + a -p^) (1 -p) , 

and the probability of making a wrong decision: 

1 - Pr = (1-Pd>-P + (l-Pl-Pn 

If is the loss associated with a Type I error 
(a = (1 ” *P) ^2 loss associated with a Type II 

error (B = (1 -p) *Pn) r the expected loss for a wrong decision 
is 



E(L) = a*Lj^ + 3*L2 

Let's start with the assumption that the target is detected 
if it is detected with either sensor A or sensor B or both, 
that is (A u B) . The improvement "I" can be defined as in 
Figure 6.5, which in percentage terms becomes; 
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I [ (A u B) ,A] 



P(1-P^(A) ) -P^(B) •L^-d-p)P^(B) (l-P^(A) -L^ 
p(l-P^(A)) •L^+(l-p)P^(A) -L^ 

Let's now quantify a question that often arises. Suppose 

we suspect that there is a target in the data batch from the 

sensors. The sensor being used has a fairly low probability 

of catching it. How much do we gain by adding a second sensor 

also of low catching probability? Assuming that P^ (A) = P^(B) 

= P, and that P (A) = P (B) = P , we have: 
d n n n 



I [ (A u B) ,A] 



100 X 



p(l-P^) -P 
p(l-P 



d 

d 



•L. - (1-p) P (1-P ) -L^ 
1 ^ n n 2 

) -L^+ (1-p) 



Assuming also that P^ = .3, = 50, = 10, p e [.1,19], 

and P^ € [.1,19], we can have some sample curves with a 

simple BASIC program (see Appendix A) . Two looks are not 
always better than one. We could require that both trials 
A and B (A u B) detect a target before a target is said to 
have been detected. Such a procedure would decrease the 
number of false alarms at the cost of missing more targets. 

If detection by both A and B (A nB) is required, then 

P^(AnB) = 

P (A n B) = P (A) • P (B) 

n n n 

The equation for the expected loss from a wrong decision 
is : 
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E(L(A n B) ) 



= p(l-P^(A)P^(B) ) -L^ + (l-p)P^(A)P^(B) -L^ 



The equation of improvement is 



I[(AnB),A] = (E(L(A) - E ( L ( A n B) ) ) /E (L ( A) ) 



or 



p-P. (A) (1-P. (B) ) *Lt + (1--p)P^ (A) (l-P^(B) ) -L. 

T = inn X_— 9 E i ^ n n 2 

p(L-P^(A) ) .L^+(l-p)P^(A) -L2 

Again for a range of reasonable values of p, P^, P^, and 
~L^, we can have some sample curves that show that in any 
case we have improvement detecting by both A and B sensors. 
The possibilities of using three or four trial combinations 
using the intersection concept is obvious. 

E. THE "WHAT THE ENEMY IS GOING TO DO" MODEL 

If whether the enemy will cross, for example, a river is 
a possibility whether or not it is true, can be regarded as 
hypotheses and the data from the intelligence subsystem can 
be related to the hypothesis. In a simple example, we can 
make the following formalism: 

H = hypothesis that the enemy will cross the river 
H' = hypothesis that the enemy will not cross the river 
D = data from the intelligence subsystem 
B = the intelligence background 
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P(h[b) = probability assigned to the truth of H 
given the truth of B 

P(h[d,B) = probability assigned to the truth of H 

given the truth of D and B 

P(D[h,B) = probability assigned to the truth of D 

given the truth of H and B. 

Now we want an expression for P(h|d,B) in terms of H , D, B 
and H* because we want to accept, reject, or modify the 
hypothesis in light of the data from the field under differ- 
ent states of knowledge. This expression will be a Bayes 
equation : 



p(h|d,b) 



P (D 


H,B) *P (H 


Ib) 


P (D| H,B) *P (D| 


1 B) + P (D 


1 H ' ,B) *P (H ' 


1 B) 



In order to make the scenario more realistic, let us assign 
the following concrete meanings of the above formalism. 



P (H I B) 
P (H ' I B) 
P (H I D,B) 
P (d[h,b) 

P (D| H ' ,B) 



the analyst's assignment of probability 
to H after reviewing the background B 

the analyst's assignment of probability 
to H ' after reviewing the background B 

the probability of H after data from the 
field 

the probability assigned to the truth 
of the data from the field, assuming the 
truth of H and B 

the probability assigned to the truth of 
data from the field assuming that B is 
true and H is false or H ' is true. 



Now we want to know whether P(H|D,B) goes to "0" or to "1" 
or stays unchagned. In other words, we want P(h|D,B) to move 
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to "0" or to "1". This is because, if I have a hypothesis 
that doesn’t move, I had better set up another more sensitive 
hypothesis. To make this point of view clearer, by diving 
the right side of Bayes' equation through by the numerator, 
we have : 



P(H|D,B) 



1 



1 ^ P(D 


H ' ,B) *P (H ' 


B) 


P (D| 


|H,B) *P (H 1 


|B) 



or 



P(H|D,B) = 



1 + 



P (dIh ' ,B) * (1-P (H I B) ) 



P (D[H,B) *P (HI B) 



Dividing this ratio through by P(D|H',B) we have; 



1 


1 


- P(H 


B) 


1 4 . 


H,B) *P (H 


B) 



p(d1h' ,B) 



That is, if H is in question, then; 



p(h|d,b) 



f( 



P (D 


H,B) 


P (D 


H' ,B) 



This is an equation of low resolving power, but in the con- 
text of this point of view, two issues can be made clearer; 

1. Suppose we developed the hypothesis, but the background 
was such that P(h|b) was only 1/2. The question is; "How 
can I get my hypothesis closer to certainty ("1") or to 
uncertainty ("0")?" Say that P(h|d,B) = .8. If I solve the 
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preceding equation, the ratio P (D 1 H ,B) /P (D 1 H ' , B) must be 
equal to 4 . This means the data from the field D must be 
4*B truer on H than it is on H', in light of the intelligence 
background B. It is clear from this that a prudent indiffer- 
ent hypothesis must collect a lot of critical experimental 
data . 

2. An equivalent but perhaps more graphic illustration can 
be set up this way: Suppose P(h|b) = .8, which means we are 

pretty sure from B that the enemy will cross the river. After 
we get the data from the field, we find that P(d1h,B) = .5, 
and P(d|h',B) = .5, which might mean that the reports can't 
be preferentially assigned to H or H', considering the back- 
ground B . Then 



P (H D,B) 



1 + 



1 

(1 - . 8) /.5 
.5*. 8 



. 8 



As common sense suggests, there can be no change between 
P(h|b) and P(h1d,B) when 



p(d1h,b) = p(d|h',b) 



but we can also argue that if the data from the field cannot 
change a prior hypothesis, there is in effect no learning 
from the data. 
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Figure 6.2s Unconditioned Probability Space. 
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Figure 6.5: Improveiaent. of Later Sensors over Firsl. Sensor. 



VII. EPILOG 



The primary purpose of this study was to produce a con- 
ceptual fram.ework that would outline from a system's context 
how a SACS (Staff Assistant Computer System) would be used 
to support staff operations within the LAE (Large Army Forma- 
tion) . Another purpose was to present some mathematical models 
for assisting the intelligence inference beyond the experience 
and the perception or intuition of the intelligence analyst. 
Thus this study had two main objectives. The first was to 
develop concepts for using a SACS to assist in accomplishing 
critical functions, duties, and tasks that must be performed 
within those command and control elements of the LAE which 
will be affected by the introduction of the SACS. The study 
in part was elaborated to provide as much detail as possible 
(the interface with a LAE wasn't possible) in a conceptual 
system description. This foundation is needed by developers 
to continue the analysis to the next level of a detailed study 
dealing with the behavior and skills associated with the 
design, development, and use of the several sets of hardware 
and software. 

Through the analytical effort involved in satisfying the 
first objective of the study, it was possible to identify 
critical command and control duties related to the military 
intelligence, that appeared impossible to perform effectively 
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given current manual procedures and projected SACS software 
capabilities. Thus identification of the need for new tools 
to support the intelligence inference constituted the second 
major thrust of this study. 
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